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1.0  Objectives 

The  CUSat  project  includes  many  objectives,  both  programmatic  and  technical.  The  following 
description  of  these  objectives  includes  a  brief  explanation  of  their  relevance  to  our  sponsors. 
The  programmatic  objectives  (POs)  are  laid  out  in  the  Nanosat-4  User's  Guide  (UN4-001  Rev- 
March  2005): 

•  PO  1:  Educational  outreach  to  students  in  grades  K-12 

•  PO  2:  Attendance  and  participation  at  program  Milestone  Events 

•  PO  3:  Student  involvement 

o  PO  3.1:  Involvement  of  students  at  all  levels  of  the  Nanosat  program,  including 
management,  engineering,  test,  and  hardware  assembly.  Universities  are  expected 
to  have  a  student  Program  Manager. 

o  PO  3.2:  Involvement  of  students  from  a  range  of  engineering  and  other  disciplines. 

o  PO  3.3:  Involvement  of  students  at  various  education  levels,  (e.g.  undergraduate  and 
graduate). 

o  PO  3.4:  Students  are  expected  to  present  their  designs  at  all  design  reviews. 

CUSat's  technical  objectives  (TOs)  are  the  following: 

•  TO  1:  Demonstrate  an  end-to-end  in-orbit  inspection  system 

Here,  "end-to-end,"  refers  to  the  scope  of  the  in-orbit  inspection  architecture.  CUSat 
includes  a  space  segment,  a  ground  segment,  and  a  data  segment.  Taken  as  a  whole, 
these  segments  form  an  in-orbit  inspection  system  that  autonomously  images  a  target 
spacecraft,  downlinks  this  imagery  to  the  ground,  recovers  a  three-dimensional  shape 
from  these  images,  and  conveys  them  in  a  responsive  manner  to  data  end  users. 

•  TO  1.1:  Demonstrate  space-segment  technologies  for  in-orbit  inspection 

These  technologies  address  several  Air  Force  and  NASA  needs,  including  responsiveness, 
robustness,  and  safety. 

o  TO  1.1.1:  All-GPS  guidance  and  navigation 

GPS  is  a  technology  that  is  largely  platform  independent  and  works  well  for  precision 
navigation  (both  absolute  and  relative)  in  a  variety  of  orbits.  Other  technologies, 
such  as  earth  sensors  and  star  trackers,  have  their  appropriate  applications  but  are 
not  sufficiently  broad  in  their  applicability  for  CUSat's  purpose.  This  purpose  is  to 
serve  as  demonstration  of  a  turn-key  inspection  system,  one  that  can  be  used  for 
many  different  spacecraft  without  time-consuming  and  risky  modifications.  CUSat's 
generic  design  demonstrates  responsiveness  in  that  missions  that  demand  an 
inspection  capability  can  use  an  off-the-shelf  CUSat  design  rather  than  a  custom 
one.  The  low  cost  of  an  all-GPS  system  is  another  important  reason  for  CUSat's 
implementation  of  it,  given  our  cost  constraints,  but  this  demonstration  can  also 
enable  future  low-cost  missions. 
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o ,  TO  1.1.2:Autonomous  navigation  with  carrier-phase  differential  GPS  (CDGPS) 

Navigation  here  refers  to  the  estimation  and  control  of  position,  along  with  higher- 
level  decision  functions. 

o  TO  1.1.3:Attitude  determination  with  CDGPS 

o  TO  1.1.4:Fault-tolerant  inspection  architecture 

Meeting  this  objective  will  demonstrate  that  a  low-cost  system  can  be  fault  tolerant 
without  depending  on  redundant  devices,  but  rather  by  cross-strapping  critical 
functionality  among  multiple  subsystems. 

o  TO  1.1.5:Collision-Free  Navigation 

This  objective  is  achieved  as  a  combination  of  functions,  including  the  mission  design 
(orbit  mechanics),  fault  tolerance,  and  precision  navigation 

•  TO  1.2:  Demonstrate  ground-segment  technologies  for  in-orbit  inspection. 

o  Demonstrate  ground  operations  for  autonomous  inspection 

CUSat's  concept  of  operation  is  designed  to  reach  the  "sweet  spot"  of  combined 
autonomy  and  ground-controller  interaction.  The  ground  will  be  responsible  for 
decisionmaking  regarding  changes  in  mission  phase  (such  as  separation  or  anomaly 
resolution)  but  not  in  the  day-to-day  activities.  The  telemetry  and  command  system 
is  based  on  providing  data  for  diagnosis  of  CUSat's  health  and  a  small  number  of 
critical  commands  and  uploads  but  not  for  realtime  "joystick"  control. 

o  Demonstrate  a  responsive,  distributed  ground  segment 

Northrop  Grumman  Mission  Systems  (NGMS)  has  partnered  with  CUSat,  offering 
access  to  some  of  its  ground-station  assets.  NGMS  will  work  with  CUSat  to  develop 
a  means  of  conveying  data  among  at  least  three  ground  stations  (one  in  Southern 
California,  one  in  Colorado,  and  one  in  Ithaca,  NY)  ina  way  that  allows  a  distributed 
end-user  community  to  access  the  inspection  data. 

•  TO  1.3:  Demonstrate  data-segment  technologies  for  in-orbit  inspection. 

CUSat  will  demonstrate  the  use  of  familiar  image-processing  techniques  to  create  a 
three-dimensional  shape  from  still  images  taken  in  orbit.  These  algorithms  will  run 
within  the  ground-station  software.  This  surface-map  data  will  serve  as  the  primary 
data  product  for  end  users.  The  design  of  the  spacecraft  will  be  such  that  it  can  be 
analyzed  by  these  imaging  techniques. 

•  TO  2:  Demonstrate  Nanosatellite  Technologies 

CUSat  uses  a  number  of  approaches  from  other  small  satellites.  Those  heritage 
solutions  do  not  represent  significant  value  as  demonstrations.  However,  we  will 
demonstrate  three  unique  technologies. 

o  Demonstrate  the  ACS-in-a-box  device  (the  IMI-C)  from  Intellitech  Microsystems 
Inc..  This  device  consists  of  three  reaction  wheels,  three  magtorquers,  a  three- 


4 


,  axis  magnetometer,  a  sun  sensor,  and  an  earth  sensor.  CUSat  will  demonstrate 
its  functionality,  but  the  system  will  be  able  to  perform  without  this  device. 

o  Demonstrate  rapid,  modular  assembly.  A  key  element  of  responsive  space,  this 
demonstration  will  be  realized  via  the  design  of  CUSat's  electronics  backplane, 
which  includes  modular,  common  connectors  and  a  mechanical  strategy  for 
mounting  electronics  cards  within  common-sized  shielding  boxes.  These 
components  can  be  removed  and  replaced  with  relative  ease. 

o  Demonstrate  an  all-propulsive,  pulsed-plasma  thrustser  (PPT)  attitude-control 
system.  While  the  IMI-C  provides  CUSat  with  considerable  functionality,  the 
baseline  design  includes  eight  PPTs,  in  an  eight-for-seven  redundant  attitude- 
and  position-control  actuator  suite.  The  safety  of  these  non-combustive, 
lightweight  devices  makes  them  ideal  for  inspection  of  manned  spacecraft. 

o 

2.0  Status  of  Effort 

CUSat  is  a  multi-year  effort  to  design,  build,  and  launch  an  autonomous  on  orbit  inspection  satellite  system.  CUSat 
is  a  student  project  team  in  the  College  of  Engineering  and  is  part  of  the  University  Nanosat-4  Competition,  a  two 
year,  cyclic  program  run  by  the  Air  Force  Research  Lab  (AFRL).  For  the  University  Nanosat  Competition,  student 
teams  design  their  own  mission  and  build  a  satellite  to  perform  their  mission.  Each  team  goes  through  several 
design  reviews  by  the  AFRL,  leading  up  to  a  final  review  in  which  a  single  winning  team  is  chosen.  This  team 
receives  additional  support  from  the  AFRL  and  is  given  a  launch  opportunity. 

Mission  and  Operations 

CUSat  is  Cornell  University's  entry  into  the  University  Nanosat  Competition.  CUSat's  mission  is  defined  as  follows: 

CUSat  demonstrates  an  end-to-end  autonomous  on  orbit  inspection  system.  Centimeter-level 
accurate  Carrier-phase  Differential  GPS  (CDGPS)  enables  CUSat  to  navigate  and  use  its  cameras  to  gather 
target-satellite  imagery.  In  the  Ground  Segment,  image-processing  techniques  verify  the  CDGPS  relative 
distance  and  orientation  estimates  and  provide  a  3D  model  of  the  target  satellite  for  the  user.[l] 


The  primary  goal  is  to  demonstrate  cooperative,  on  orbit  inspection.  The  driving  technology  that  helps  to  achieve 
this  goal  is  Carrier-phase  Differential  GPS,  a  differential  GPS  technique  that  allows  measurement  of  relative  vectors 
between  antennas  with  better  than  1cm  accuracy.  By  using  two  identical  satellites  with  three  GPS  antennas  each, 
CUSat  is  able  to  measure  relative  vectors  between  the  two  satellites  and  gain  an  attitude  estimate  of  each 
individual  satellite.  This  data  is  used  to  direct  visual  inspection  using  on-board  cameras.  The  acquired  images  are 
then  downlinked  to  a  ground  station  for  3D  reconstruction. 

Both  satellites  will  launch  in  a  single  stack  as  a  secondary  payload  on  the  launch  vehicle.  After  separation  from  the 
launch  vehicle,  the  stack  will  power  on  and  begin  to  charge  its  batteries.  The  stack  will  then  initiate  ground 
communication.  After  a  system  checkout,  the  ground  will  issue  a  command  for  the  stack  to  separate.  Once 
separation  has  occurred,  the  satellites  will  enter  an  autonomous  inspection  mode  where  pictures  are  taken 
automatically  when  the  opportunity  arises.  The  ground  stations  will  then  request  these  images  for  download.  [2] 
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Program,  Structure 

CUSat  has  historically  followed  a  project-oriented  structure.  Professor  Mason  Peck,  the  Principal  Investigator,  is  in 
charge  of  all  project  operations.  The  Program  Manager,  typically  a  student  who  has  been  with  the  program  for  a 
long  time,  reports  to  Professor  Peck.  Work  on  CUSat  is  then  divided  up  into  several  subsystems.  Each  subsystem 
has  a  lead  which  reports  to  the  Program  Manager. 


Program  Schedule  and  Milestones 

The  AFRL  specifies  that  the  following  reviews  take  place  for  all  entrants  to  the  competition: 

•  Systems  Concept  Review  -  May  2005 

•  Preliminary  Design  Review  -  August  2005 

•  Critical  Design  Review  -  February  2006 

•  Proto-Qualification  Review  -  August  2006 

•  Flight  Competition  Review  -  March  2007 

In  addition  to  these  reviews,  CUSat  conducted  several  internal  reviews  described  later  in  this  report. 

Design  Maturity 

CUSat  delivered  one  fully  functional  prototype  flight  unit  for  the  Flight  Competition  Review  (FCR).  This  unit 
contained  a  complete  and  functional  electrical  bus.  Most  custom  printed  circuit  boards  (PCBs)  were  professionally 
populated  by  Northrop  Grumman  Space  Technology,  the  remainder  were  assembled  in-house.  The  proto-flight 
unit  also  contained  a  complete  structure.  Most  structural  components  were  machined  in-house.  Several 
components  were  manufactured  by  Moog,  Inc.  Space  Systems.  Since  the  proto-flight  hardware  was  intended  to  be 
used  for  the  actual  flight  units,  all  of  it  was  appropriately  tracked  per  the  CUSat  Configuration  Management  and 
Quality  Assurance  (CM/QA)  Plan. 

On  the  subsystem  level,  the  vast  majority  of  hardware  was  delivered  except  for  several  large  ticket  items.  These 
large-ticket  items  included  the  inter-satellite  Motorized  Lightband  Separation  System,  flight  solar  cells  and  solar 
cell  honeycomb  panels.  Most  of  these  were  excluded  because  of  budget  constraints. 

The  purpose  of  the  prototype  build  was  to  demonstrate  the  ability  of  the  team  to  deliver  functional,  high  quality 
hardware.  Another  purpose  of  the  prototype  was  to  identify  any  integration  issues  and  unresolved  design  issues. 
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Figure  1  -  FCR  Hardware  Design  Maturity  |3| 

Flight  Competition  Review  (FCR) 

The  Flight  Competition  Review  served  as  a  major  design  review  milestone.  However,  the  main  purpose  of  the 
review  was  to  allow  the  AFRL  to  choose  a  winning  team  to  which  they  would  offer  continued  support  and  a  launch 
opportunity.  For  the  competition,  one  of  the  author’s  main  responsibilities  was  to  develop  a  plan  to  complete  the 
program  upon  a  win  at  FCR.  This  document  was  labeled  the  Post-FCR  Action  Plan  (CUSAT-SYS-0026)[3]  and 
constitutes  a  large  portion  of  the  work  for  the  initial  sections  of  the  report. 

Cornell’s  entry  was  chosen  as  the  winner  of  the  competition  based  on  technical  merit,  relevance  to  the  AFRL, 
program  documentation,  as  well  as  several  other  factors.  As  a  result  of  this  decision,  the  AFRL  committed  to 
supporting  the  program  through  completion.  This  necessitated  heavy  planning  for  delivery  of  hardware  qualified  for 
space  flight,  software  that  was  thoroughly  tested,  and  a  ground  support  system  capable  of  running  the  mission. 

Program  Deliverables  and  Goals 

Completion  of  the  CUSat  program  is  contingent  upon  delivery  of  several  large  items: 

•  Flight  Hardware 

Two  identical  satellite  units  that  satisfy  the  hardware  requirements  set  forth  in  the  CUSat 
Requirements  document.  Problems  identified  with  the  proto-flight  unit  needed  to  be  fixed, 
whether  by  physical  changes  to  the  hardware  or  modifications  to  the  design.  Additionally,  a 
full  two  sets  of  flight  hardware  plus  several  spare  pieces  of  hardware  needed  to  be 
manufactured.  Hardware  delivery  is  contingent  upon  a  successful  integration  process  as  well 
as  a  rigorous  and  well  documented  testing  process. 

•  Flight  Software 

Flight  software  includes  embedded  code  for  smaller  systems,  baseline  code  for  the  flight 
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computer,  high-level  control  code,  as  well  as  filters,  estimators,  and  controllers.  All  of  this 
software  needs  to  be  verified  on  the  ground  through  a  combination  of  simulation  and  test. 

•  Ground  Stations 

Well  designed  and  maintained  ground  stations  are  essential  for  mission  success.  Final 
delivery  requires  that  ground  stations  be  ready  to  receive  telemetry  and  send  commands.  A 
central  server  and  ground  station  network  also  needs  to  be  complete.  Hardware  acquisitions 
(such  as  antennas)  are  also  key  to  ground  station  delivery. 

•  Mission  Operations 

Well  defined  operating  procedures  as  well  as  trained  operators  are  also  critical  for  mission 
success.  Part  of  the  overall  delivery  package  includes  a  team  capable  of  handling  routine  as 
well  as  unforeseen  operating  conditions  for  the  lifetime  of  the  CUSat  mission.  This  team 
needs  to  maintain  knowledge  across  generations  of  graduates. 


Scope  of  this  Report 

The  scope  of  this  project  includes  work  done  by  the  author  after  the  Flight  Competition  Review  (FCR).  At  this  point, 
the  project  had  been  in  progress  for  about  two  years.  This  project  focused  on  bringing  a  prototype  system  through 
delivery  as  a  flight-ready,  robust,  tested  system.  The  report  is  split  into  four  sections. 

Program  Management 

Leading  the  CUSat  team  towards  completion  of  the  flight  units  was  the  primary  purpose  of  this  project.  The  report 
details  planning  for  the  flight  build  as  well  as  several  reviews  and  other  tools  that  were  used  to  accomplish  goals  set 
forth  in  the  beginning  of  the  semester.  Regular  communication  between  the  AFRL,  the  University,  Professor  Peck, 
and  team  members  was  also  a  key  part  of  the  project.  Program  schedule,  budget,  and  organization  are  all  covered  in 
this  section  of  the  report. 

Camera  Interface  Board  (CAM  IB) 

This  semester,  a  lot  of  technical  work  was  done  to  redesign  the  Camera  Interface  Board  (CAM  IB)  after  identifying 
serious  design  flaws  during  FCR.  This  section  of  the  report  outlines  system  requirements,  describes  the  design 
process,  and  shows  how  the  design  met  the  requirements. 

Power  Board  Completion 

Power  board  design  was  done  as  a  senior  honors  project.  FCR  integration  exposed  several  design  flaws  with  the 
safety  inhibit  design.  These  flaws  were  addressed  as  part  of  this  project.  The  updated  design  is  described  in  this 
section  of  the  report. 

System  Level  Trade  Studies  and  Analysis 

This  project  also  dealt  with  several  system-level  design  decisions.  There  were  also  several  specific  design  tasks 
relating  to  hardware  work.  All  of  these  tasks  contribute  to  the  larger  goal  of  creating  a  flight-ready  system  to  meet 
program  requirements  and  accomplish  mission  objectives. 
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Program  Management 

This  section  details  the  work  done  to  plan  for  final  delivery  to  the  AFRL.  A  large  portion  of  this  work  was  done 
before  FCR  to  demonstrate  the  ability  of  our  program  to  finish  and  our  desire  to  deliver  a  complete,  functional 
system.  Planning  was  required  on  several  levels.  First,  a  budget  needed  to  be  developed  to  ensure  that  delivery  was 
not  impeded  by  funding  constraints.  Also,  a  large  portion  of  the  team  was  graduating  at  the  end  of  the  year,  so  a  well 
thought-out  recruitment  effort  was  essential  to  continued  program  success.  Remaining  design  work  from  issues 
identified  during  FCR  also  needed  to  be  planned  for.  Finally,  the  extensive  integration  and  testing  process  needed  to 
be  spelled  out  and  scheduled  to  ensure  success. 

Post-FCR  Action  Plan 

The  Post-FCR  Action  Plan[3]  was  a  major  first  step  in  the  planning  process.  A  current  budget  was  presented  to 
demonstrate  the  ability  to  finish  the  program  given  extended  AFRL  funding.  Remaining  build  and  design  issues 
were  also  presented  to  give  an  honest  yet  hopeful  timeline  for  flight  unit  delivery.  An  assembly,  integration,  and  test 
(AI&T)  schedule  was  also  presented  to  show  our  expected  completion  time. 

Project  Level  Goals 

The  following  goals  were  identified  as  necessary  for  successful  project  completion: 

1.  Resolve  remaining  design  issues  identified  after  FCR . 

During  the  prototype  build,  several  design  issues  were  identified.  These  ranged  in  severity  from  very  minor 
(improperly  sized  bolts)  to  severe  (lack  of  ability  to  build  solar  panels).  To  ensure  successful  resolution  of  these 
issues,  a  post-FCR  debriefing  meeting  was  held.  A  system-wide  list  of  outstanding  actions  was  assembled  and 
specific  actions  were  assigned  to  specific  team  members.  Team  members  were  informed  that  their  grade  for  the 
coming  semester  directly  depended  on  their  ability  to  resolve  these  issues. 

Several  issues  were  identified  as  beyond  the  scope  of  a  particular  subsystem  or  beyond  the  expertise  of  certain  team 
members.  These  issues  included: 

•  Solar  Panel  Construction 

•  Communications  Antenna  Design 

These  trades  are  addressed  directly  later  in  this  report. 

2.  Finish  machining  of  structural  and  propulsion  components . 

Design  of  a  machining  schedule  and  finalization  of  part  drawings  was  assigned  to  Ofer  Eldad,  the  mechanical  lead. 
With  Ofer’s  guidance,  the  structural  design  and  manufacturing  teams  on  CUSat  were  was  able  to  lay  out  a 
machining  schedule  and  finish  major  machining  efforts  on  time. 

3.  Finish  design  and  build  of  electrical  subsystems. 

Several  electrical  systems  required  direct  attention.  These  included: 

•  Camera  Interface  PCB 

•  Propulsion  Electronics 

•  Power  PCB  Redesign 

These  designs  are  addressed  directly  later  in  this  report. 
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4.  Rigorously  test  subsystem  hardware. 

5.  Integrate  and  test  all  hardware  to  verify  system  requirements. 

While  test  plans  had  been  developed  before  FCR,  most  of  them  had  not  been  run  on  hardware  and  were  inadequate 
for  requirement  verification.  Part  of  the  work  done  this  semester  included  setting  up  a  testing  process  and  training 
new  members  to  carry  out  the  tests. 

6.  Maintain  a  program  budget  to  ensure  adequate  funding. 

An  overall  budget  was  developed  as  part  of  the  Post-FCR  Action  Plan.  This  is  included  in  this  report. 

7.  Develop  comprehensive  ground  support  and  mission  operations  systems  and  train 

personnel. 

Two  major  milestones  for  the  ground  segment  this  semester  were  acquisition  of  ground  station  software  and  the 
formation  of  the  mission  ops  team.  A  mission  ops  team  was  formed  this  semester  with  the  goal  of  developing  a 
coherent  set  of  recommended  operating  procedures  (ROPs)  for  ground  station  operation.  Ground  station  software 
trades  are  discussed  later  in  this  report. 

Budget 

A  forward  looking  budget  was  developed  for  the  Post-FCR  Action  Plan.  Each  foreseen  expenditure  was  listed  by 
subsystem.  The  results  are  summarized  in  Table  1. 


Table  1  -  Preliminary  Budget  |3| 


Subsystem 

Resources  Required 

Cost 

ADCNS 

None 

$0 

$0 

CAM 

Additional  Cameras 

$5,000 

Additional  FPGA  Boards 

$3,500 

Lenses 

$2,550 

$2,550 

CDH 

Additional  Flight  Computer 

$550 

$550 

GPS 

None 

$0 

$0 

HARN 

Additional  Connectors/Supplies 

$500 

Fabrication  of  Flight  PCBs 

$4,000 

$4,500 

l&T 

Support  Equipment/Materials 

$5,000 

$5,000 

PROP 

PPU  Electronics  Fabrication 

$4,000 

PPT  Stock/Manufacture 

$500 

PPT  Wiring  Harness 

$2,500 

Busek  Testing 

$500 

$4,500 

PWR 

Fabrication  of  Flight  PCBs 

$2,000 

Solar  Cells 

$76,750 
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$108,750 

Fabrication  of  Flight  PCBs 

$1,000 

T&C 

Antenna  Fabrication 

$500 

$1,500 

Honeycomb  Panels 

$5,000 

STR 

Motorized  Lightband 

$80,000 

$225,000 

Antennas/RF  Equipment  and  Computers 

$0 

GS 

MAESTRO  and  GUI 

$0 

Other 

Other  Expenses 

$10,000 

$10,000 

Total  Program  Cost  Remaining: 

$208,350 

Personnel 

A  large  number  of  experienced  CUSat  members  were  graduating  at  the  end  of  the  spring  semester.  In  order  to 
mitigate  the  risk  of  losing  knowledge,  an  aggressive  recruitment  process  was  started  before  the  end  of  the  semester. 
Team  leads  were  asked  to  submit  a  list  of  jobs  that  needed  to  be  filled.  Several  information  sessions  were  run  and 
advertisements  were  put  out  to  attract  new  students  to  the  team.  Students  were  encouraged  to  fill  out  an  application 
form  and  submit  it  to  the  team  leadership.  After  interviewing  prospective  candidates,  the  team  leads  were  asked  to 
submit  a  list  of  candidates  that  they  wanted  to  accept. 

In  order  to  acclimate  new  members,  an  orientation  session  was  run.  This  consisted  of  a  Powerpoint  presentation  that 
described  the  team  history,  progress,  documentation  procedures,  and  how  to  use  the  team  website.  New  members 
were  assigned  documentation  to  read  before  starting  work  [4]. 

Schedule 

A  long  term  delivery  schedule  was  designed  for  the  Post-FCR  Action  Plan.  The  schedule  sets  hardware  delivery  in 
January  of  2008.  The  AFRL  has  requested  that  we  stick  to  this  schedule  and  deliver  flight  hardware  between  January 
and  March  of  2008. 
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Figure  2  -  Post-FCR  System  Schedule  |3| 


Figure  3  -  Post-FCR  System  Schedule  (ctd)  |3| 
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While  the  overall  program  schedule  was  defined  before  FCR  as  shown  in  Figure  2  and  Figure  3,  a  more  detailed 
schedule  was  set  up  using  Microsoft  Project  to  keep  the  team  on  track.  This  schedule  was  kept  up  to  date  on  the 
internal  website  and  was  updated  weekly  at  the  leads  meetings.  Specific  tasks  and  deadlines  were  assigned  directly 
to  different  team  members.  An  example  of  part  of  this  schedule  is  shown  below  in  Figure  4. 


Figure  4  -  Detailed  Program  Schedule  Example  [5| 

In  addition  to  tracking  action  items  by  team  member  and  subsystem,  a  Hardware  Status  Chart  was  also  developed. 
This  chart  gave  an  overall  picture  of  the  current  hardware  status  using  different  colors  to  indicate  varying  levels  of 
risk  and  completeness.  This  was  particularly  useful  to  see  what  parts  were  slipping  behind.  It  also  provided  another 
source  of  schedule  for  team  members  who  were  averse  to  using  Microsoft  Project.  An  example  of  this  is  shown  in 
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Figure  5  -  Hardware  Status  Chart  |6| 
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Communications 

Weekly  meetings  were  held  on  three  levels  to  discuss  progress  and  high-level  issues.  These  meetings  occurred  every 
Monday  and  helped  to  foster  communication  between  people  working  on  various  levels  of  the  project. 

Leads  Meeting 

This  meeting  involved  all  of  the  subteam  leads.  Weekly  progress  was  discussed.  This  gave  the  leads  a  chance  to 
work  out  some  inter-subsystem  issues.  The  system  level  schedule  was  also  discussed  and  updated  at  each  of  these 
meetings.  At  the  end  of  each  meeting,  action  items  were  assigned  to  various  leads. 


Meeting  with  Professor  Peck 

This  meeting  included  the  PI  (Professor  Peck),  the  PM  (the  author),  and  the  lead  mechanical  systems  engineer  (Ofer 
Eldad).  The  purpose  of  this  meeting  was  to  update  Professor  Peck  on  the  team  status  as  well  as  to  work  out  high- 
level  issues,  such  as  those  dealing  with  the  University  or  the  AFRL.  Professor  Peck  would  also  offer  technical 
advice  when  the  team  would  encounter  a  particularly  difficult  problem. 


AFRL  Tele  con 

This  weekly  phone  conference  consisted  of  a  small  group  of  subteam  leads  as  well  as  the  lead  Systems  Engineer  and 
Program  Manager  for  the  University  Nanosat  Program  at  the  AFRL.  The  purpose  of  the  conference  was  to  update 
the  AFRL  as  to  team  status  and  work  out  delivery  related  issues.  The  AFRL  would  also  offer  technical  advice. 

Integration  and  Testing 
Goals 

The  overall  purpose  of  the  Integration  and  Testing  (I&T)  effort  was  to  satisfy  system  level  goal  number  (5).  Several 
lower  level  goals  were  derived  to  accomplish  this  test. 

1.  Implement  and  enforce  rigorous  Configuration  Management  and  Quality  Assurance 
(CM/QA)  procedures. 

2.  Develop  meaningful  test  procedures  that  verify  system  and  subsystem  level  requirements. 

3.  Test  all  flight  hardware  and  run  integration  tests  using  rigorous  test  procedures. 

CM/QA  procedures  were  already  well  defined  at  the  start  of  the  project  based  on  AFRL  recommendations.  The  main 
challenge  was  gaining  momentum  in  the  testing  area.  Most  I&T  members  were  new  and  unfamiliar  with  the 
hardware  and  the  testing  process.  To  kick-start  the  process,  the  author  organized  and  helped  with  several  initial 
hardware  tests.  Once  the  testing  phase  had  started,  the  I&T  team  members  were  able  to  continue  the  process  and 
develop  high-quality  test  procedures. 

Ground  Segment  and  Mission  Operations 

Up  until  FCR,  the  ground  segment  and  mission  operations  had  received  significantly  less  focus  than  the  space 
segment.  It  was  recognized  that  these  sectors  of  CUSat  would  play  a  pivotal  role  as  hardware  development  came  to 
an  end.  As  a  result,  a  large  part  of  the  team  (about  one  third)  was  devoted  to  ground  segment  and  mission  operations 
work. 
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Reviews 

Several  reviews  were  held  as  stage-gates  to  ensure  that  the  team  was  on  task  and  to  provide  concrete  deadlines  that 
had  to  be  met.  Some  of  these  reviews  were  on  the  team  level,  but  others  included  industry  experts  and  the  AFRL. 

Post-FCR  Review 

The  Post-FCR  Review  was  designed  to  make  sure  that  issues  identified  during  FCR  were  not  ignored  and  forgotten. 
For  the  review,  each  team  met  with  the  program  manager  and  outgoing  program  manager  to  discuss  issues  with  their 
subsystem.  These  issues  were  recorded  and  turned  into  action  items.  This  list  of  action  items  was  used  as  the 
deliverable  list  for  the  subteam  in  the  next  semester.  These  are  included  in  the  appendix. 

Red  Team  Review 

This  review  took  place  on  September  28th,  2007.  Attendees  included  industry  experts  and  AFRL  employees.  The 
review  was  an  all-day  event  that  consisted  of  several  presentations  where  the  reviewers  were  encouraged  to  ask 
questions  and  write  down  action  items.  Presentations  were  design  to  show  the  current  state  of  the  program  and  to 
encourage  discussion  about  high-risk  and  still  unresolved  issues  with  the  design  [7]. 

Operations  ROPs  Review 

This  internal  review  took  place  mid-semester.  The  purpose  was  to  review  the  first  draft  of  several  of  the 
Recommended  Operation  Procedures  (ROPs)  designed  by  the  mission  operations  team.  Team  members  gave 
feedback  and  assigned  action  items  to  each  of  the  ROPs. 


15 


Camera  Interface  Board  (CAM  IB) 

The  original  Camera  Interface  Board  (CAM  IB)  design  used  four  boards: 

•  The  Heron  FPGA5  board 

This  board  was  used  to  capture  image  data  from  the  cameras. 

•  The  Heron  Base  board 

The  FPGA5  board  mounted  directly  to  this  board.  The  Base  board  provided  power  to  the 
FPGA. 

•  The  CAM  IB 

This  board  interfaced  between  the  Heron  FPGA5/Base  and  the  flight  computer  through  the 
Jumper  Board.  It  was  mounted  on  standoffs  on  the  side  of  the  camera  electronics  enclosure. 

•  The  CAM  IB  Jumper  Board 

This  board  held  the  connector  for  the  box  enclosure  and  jumper  wires  from  the  connector 
to  the  CAM  IB. 

The  decision  was  made  to  replace  the  Heron  Base  board  as  well  as  the  side  board  with  a  single  Camera  Interface 
Board  (CAM  IB).  See  the  Trade  Studies  section  for  details  on  this  decision.  The  CAM  IB  had  the  following  derived 
requirements: 

1.  The  CAM  IB  shall  provide  all  necessary  functionality  for  the  FPGA5  board  originally  provided 
by  the  Heron  Base  board. 

2.  The  CAM  IB  shall  provide  an  RS-485  link  to  the  Heron  FPGA5  board. 

3.  The  CAM  IB  shall  provide  an  interface  to  the  flight  computer  as  specified  by  the  Electrical 
ICD. 

4.  The  CAM  IB  shall  be  capable  of  reprogramming  the  Heron  FPGA5  using  JTAG. 

To  satisfy  requirement  (1),  several  documents  from  Heron  were  obtained  [8,9,10],  These  documents  provided  exact 
dimensions  of  the  Heron  FPGA5  board  as  well  as  descriptions  of  most  of  the  interface  pins.  However,  the  interface 
used  was  designed  for  much  more  complicated  systems  and  many  pins  were  unused  on  the  Heron  Base  board.  A 
diagram  of  the  Base/FPGA  board  setup  is  shown  in  Figure  6. 
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Figure  6  -  Diagram  of  the  Heron  Base  Board  |8| 


Schematic 

Using  the  signal  list  from  the  specification,  each  pin  on  the  base  board  was  probed  to  measure: 

•  Resistance  to  ground 

•  Resistance  to  5V 

•  Resistance  to  3.3V 

•  Voltage  when  the  board  was  powered 

Unfortunately,  these  measurements  were  recorded  by  hand  and  are  not  included  in  the  report.  However,  the  circuit 
diagram  in  Figure  7  shows  the  results  of  the  analysis. 

This  allowed  the  elimination  of  many  unused  features  in  the  spec.  After  many  checks  to  the  recorded  measurements, 
a  schematic  was  drawn  for  the  CAM  IB.  The  schematic  mimicked  the  connections  as  they  were  done  on  the  Base 
board. 
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In  situations  where  the  exact  connection  for  a  pin  was  unclear,  several  “do  not  load”  (DNL)  resistors  were  placed  to 
allow  the  populator  of  the  board  to  change  the  functionality  if  necessary. 

5V  and  3.3V  lines  were  required  for  the  CAM  IB  microcontroller  and  FPGA  board.  These  were  generated  using  the 
following  circuit: 


Figure  8  -  CAM  IB  Power  Regulation 

The  PT78ST105H  is  a  switching  regulator  that  outputs  5V  at  up  to  1.5 A,  more  than  sufficient  for  the  FPGA  and 
microcontroller.  This  device  is  recommended  by  the  Electrical  ICD  (CUSAT-SYS-01 1).  The  MAX4372T  is  a 
current-sense  amplifier  used  to  measure  the  current  output.  The  LM3480  is  a  small  package  3.3V  linear  regulator 
and  was  chosen  since  the  3.3V  line  is  used  only  for  low  power  applications.  Originally  a  plan  was  in  place  to  use 
separate  analog  and  digital  grounds,  however  there  was  no  sensitive  analog  circuitry  onboard,  so  these  grounds  were 
connected  here. 

For  RS-485  communication,  the  MAX3083  chip  was  used  as  specified  in  the  Electrical  ICD  (CUSAT-SYS-01 1). 
One  chip  was  used  for  CUCP  communication  while  another  was  used  for  communication  with  the  FPGA. 


0  luF 
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A  5V  to  3.3V  level  converter  was  required  for  JTAG  signals  and  some  FPGA  signals,  such  as  the  reset  line.  A  3.3V 
to  5  V  level  converter  was  not  required  since  the  microcontroller,  which  runs  off  of  5  V,  considers  any  level  above 
3.0V  as  “high”.  The  TC74LCX244FT  octal  buffer  chip  was  chosen  as  it  can  be  used  as  a  level  converter.  Enable 
lines  were  tied  to  the  microcontroller  for  additional  functionality. 
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Figure  10  -  CAM  IB  Level  Converter 


The  microcontroller  used  was  the  Atmel  ATMEGA128,  as  specified  in  the  Electrical  1CD  (CUSAT-SYS-01 1).  All 
control  and  sensor  lines  were  hooked  up  to  the  microcontroller. 


The  layout  of  the  camera  enclosure  box  required  the  construction  of  a  jumper  board  to  hold  the  backplane  connector. 
To  save  money,  this  board  was  built  as  part  of  the  CAM  IB  and  the  two  boards  were  cut  apart  before  population. 

The  jumper  schematic  is  shown  here: 
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Figure  12  -  CAM  IB  Jumper  Board 


Layout 


The  dimensions  of  the  board  were  specified  by  the  structures  team.  Using  structural  drawings,  an  initial  board 
outline  was  done.  Initially,  the  board  was  designed  using  two  layers;  however  it  became  apparent  that  the  routing 
was  too  complicated  and  required  more  versatility.  As  a  result,  the  board  was  upgraded  to  four  layers,  using  a  plane 
layer  for  ground  and  5V.  This  was  still  an  improvement,  however,  over  the  old  design  which  used  six  layers. 

The  connectors  to  the  FPGA  and  backplane  were  placed  first  since  their  locations  were  specified  by  the  Heron 
specification.  The  resultin 


Figure  13  -  CAM  IB  Layout 
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Power  Board  Completion 
Power  Subsystem  Circuit  Boards 


System  Requirements 

PWR  S3.  Power  distribution  shall  be  centralized. 

Source:  I&T  S2 


PWR  S3.1. 
PWR  S3.2. 
PWR  S3.2.1. 
PWR  S3.2.2. 
PWR  S4. 


Power  shall  be  capable  of  toggling  the  powered  state  of  all  other  subsystems. 

Power  regulation  shall  be  distributed. 

PWR  shall  monitor  all  distribution  line  voltages. 

PWR  shall  monitor  all  distribution  line  currents. 

PWR  shall  contain  the  safety  inhibits. 

Source:  UN4-001ASec.  5.1 


PWR  S4.1.  The  safety  inhibits  shall  have  double  fault  tolerance  on  the  positive  potential  of  any 

power  source. 

PWR  S4.2.  While  enabled,  the  safety  inhibits  shall  prevent  power  flow  from  any  power  source 

on  CUSat  prior  to  Launch  Vehicle  separation. 


PWR  S4.2.1. 


[11] 


Safety  inhibits  shall  be  disabled  via  separation  microswitches  on  the  Launch  Vehicle 
Lightband. 


Engineering  Work 

Upon  testing  of  the  FCR  power  boards,  several  issues  were  found  with  the  safety  inhibit  switches.  The  safety 
inhibits  consisted  of  relays  designed  to  prevent  powering  of  the  spacecraft  before  separation.  Testing  during  FCR 
showed  that  the  FCR  design  satisfied  requirements  PWR  S6  through  PWR  S6.22.  However,  further  testing  showed 
that  flaws  in  the  design  of  the  safety  inhibit  circuit  prevented  the  circuit  from  fulfilling  requirement  PWR  S7.2.1  as 
the  inhibits  were  never  disabled. 

The  safety  inhibits  are  implemented  using  four  Leach  XL-A1A  relays.  These  are  high  reliability,  hermetically  sealed 
relays  that  latch  once  they  are  switched.  The  relays  are  initially  switched  off  during  launch.  After  separation  from 
the  launch  vehicle,  microswitches  on  the  separation  system  will  allow  current  to  flow  from  the  solar  arrays  to  the 
relay  coils.  The  root  cause  of  this  was  shown  to  be  improper  grounding  of  the  circuit,  which  caused  current  to  flow 
through  the  unpowered  microcontroller  and  did  not  allow  the  relays  to  switch.  As  a  result,  a  new  design  was 
required  along  with  a  new  revision  of  the  power  boards. 

In  addition  to  fixing  the  grounding  issue,  several  other  optimizations  were  made.  One  optimization  was  the  ability  to 
switch  off  the  circuit  that  drove  the  inhibit  relay  coils.  This  was  desired  because  the  coil  driver  circuit  utilized  a 
boost  converter  that  did  not  need  to  be  powered  after  the  relays  flipped.  The  power  draw  was  significant  and  noise- 
inducing,  so  it  was  deemed  worthwhile  to  change  the  design. 

The  safety  inhibits  work  by  prohibiting  current  flow  between  power  sources  and  loads.  The  AFRL  requires  that 
there  be  three  independent  inhibits  between  any  two  power  sources  or  any  power  source  and  a  load  on  the  positive 
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side  and  one  on  the  negative  side.  The  diagram  below  shows  how  this  applies  to  the  CUSat  system.  The 
microswitclies  on  the  Lightband  allow  current  to  flow  once  separation  has  occurred.  A  28V  boost  converter  (called 
the  “coil  driver”  in  this  design)  produces  a  28V  power  line  for  the  relay  coils.  Each  separation  switch  then  activates 
a  control  line  that  allows  the  relay  coils  to  switch  using  the  28V  power  line.  Once  the  relays  have  been  activated,  the 
rest  of  the  system  receives  power.  The  power  system  microcontroller  can  activate  an  optical  isolator  to  disable  the 
28V  line.  Since  the  relays  are  latching,  the  28V  power  may  be  disabled  soon  after  the  microcontroller  receives 
power  without  changing  the  state  of  the  relays. 


Figure  14  -  Safety  Inhibit  Power  Flow 

The  boost  converter  used  to  drive  the  coils  is  shown  below.  The  MC34063A  is  a  switch-mode  regulator 
controller.  Component  values  were  selected  off  of  the  datasheet  example.  The  power  supply  to  the 
converter  is  controlled  by  a  MOSFET  switch  which  is  normally  pulled  low  (on).  The  INHIBIT_CTRL  line  is 
controlled  by  the  optical  isolator  in  Figure  15.  A  “do  not  load”  resistor  is  provided  to  allow  the  use  of 
12V  relays  should  the  part  become  available. 


The  output  capacitor  (C17C)  was  chosen  based  on  part  availability.  It  was  difficult  to  find  larger 
capacitors  qualified  for  space  use  with  high  enough  voltage  ratings.  The  low  value  implies  there  will  be 
notable  ripple  voltage  on  the  line.  This  is  approximately  equal  to  the  RC  decay  on  the  line  between 
switching  cycles: 

Vripfi,  =  F0(l-*_^) 

Where  V0  is  the  output  voltage,  in  this  case  28V,  R  is  the  approximate  impedance  of  the  relay  coils,  and 
/  is  the  switching  frequency  of  the  coil  driver.  The  coils  have  a  rated  resistance  of  760  Ohms.  Since 
there  are  four  of  them  in  parallel,  R  is  approximately  190  Ohms,  /  is  defined  by  C17B  as  per  the 
datasheet  of  the  controller  chip  and  is  approximately  40kHz.  This  gives  a  ripple  voltage  of  about  0.4V 
or  0.8V  peak-to-peak.  This  is  well  within  the  switching  tolerance  of  the  relays. 
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Relay  coils  are  driven  by  the  28V  line  and  are  controlled  by  MOSFET  switches  on  the  low  side.  These 
switches  are  pulled  low  (off),  but  are  activated  by  the  Lightband  microswitches.  An  optical  isolator 
allows  the  microcontroller  to  control  the  INHIBIT_CTRL  line  as  discussed  earlier.  The  optical  isolation 
removes  grounding  concerns  that  caused  the  original  failure  of  the  system. 

Note  that  although  the  ground  return  lines  of  all  power  sources  need  to  be  disconnected  before 
separation,  10  MOhm  resistors  are  used  to  prevent  buildup  of  static  charge. 


Figure  15  -  Power  Board  Inhibit  Circuit 

Changes  to  the  schematic  were  large  enough  to  force  a  complete  re-layout  of  the  power  boards.  Complete 
schematics  and  layout  pictures  are  included  in  the  appendix. 
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■  > 

System  Level  Trade  Studies  and  Analysis 

This  section  explains  several  system  level  trade  studies  that  were  completed  as  part  of  the  project. 

Solar  Panels 

System  Requirements 

PWR  S5.  Power  shall  use  solar  cells. 

PWR  S5.1.  Solar  cells  shall  provide  the  necessary  power  to  charge  the  batteries. 

PWR  S5.2.  Solar  cells  shall  provide  the  necessary  power  to  the  spacecraft  during  illumination. 

[11] 

Design  Trades 

Two  options  were  available  for  solar  panel  development.  The  first  involved  in-house  construction  of  the  panels  from 
high-efficiency  cells.  The  second  involved  an  outside  manufacturer  that  used  lower  efficiency  cells.  Major  decision 
factors  included  cost,  ease  of  integration,  risk,  and  power  generation.  The  cell  dimensions  also  mattered  in  terms  of 
ease  of  layout. 


Option  1  -  Emcore  Cells 

The  cells  offered  by  Emcore  were  28%  efficient  Advanced  Triple  Junction  cells.  These  cells  were  small  (3cmx4cm) 
allowing  for  easy  placement  on  the  panels.  Honeycomb  material  would  need  to  be  ordered  as  a  base  for  the  cells. 
These  cells  were  also  very  expensive  and  required  a  lot  of  work  to  fabricate  panels  [12]. 


Option  2  -  Spacequest 

Spacequest,  a  small  satellite  part  supplier,  was  able  to  manufacture  the  panel  assembly  for  a  cost  similar  to  the  bare 
cells  from  the  other  suppliers.  The  cells,  however,  were  of  the  larger  variety  (4cmx7cm)  and  lower  efficiency  (about 
22%).  However,  this  option  eliminated  the  need  for  expensive  honeycomb  material. 

Simulation 

A  MATLAB  simulation  was  done  to  determine  the  amount  of  operational  time  offered  by  each  of  the  trade  options. 
The  results  are  summarized  below. 

Solar  input  power  was  assumed  to  be  given  by  the  following  formula: 

P  =  (£•  N)SAEcell 

In  this  equation,  P  is  solar  power  from  a  given  face  of  the  satellite.  E  is  a  normalized  vector  pointing  from  the  center 
of  the  Earth  to  the  sun.  N  is  the  face  normal  vector.  S  is  solar  intensity  (1353  W/m2)  in  Low-Earth  Orbit.  A  is  the 
area  of  the  face  covered  by  solar  cells.  Eceu  is  the  solar  cell  efficiency.  Faces  that  generate  a  negative  solar  power 
were  ignored  since  this  indicated  that  the  faces  were  in  shadow. 

Code  was  written  in  MATLAB  to  calculate  power  generation  over  several  orbits.  This  simulation  is  also  explained 
in  the  CUSat  power  budget  document.  The  MATLAB  code  is  also  included  in  the  appendix. 

Albedo  power,  power  generated  from  light  reflecting  off  of  the  Earth’s  surface,  was  ignored  for  this  simulation. 
While  the  functionality  is  included  in  the  simulation,  at  the  recommendation  of  the  AFRL,  this  was  assumed  to 
generate  zero  power. 
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The  simulation  assumed  an  orbit  normal  pointing  scheme  as  specified  in  the  Concept  of  Operations.  Results  were 
plotted  basecl  on  inclination  angle  and  time  of  year.  Parameters  such  as  cell  efficiency,  battery  efficiency,  and  cell 
placement  were  taken  into  account. 

To  calculate  expected  power  consumption,  several  assumptions  were  necessary.  One  such  assumption  was  the 
efficiency  of  the  battery  array.  From  work  in  earlier  semesters  (detailed  in  the  CUSat  Power  Analysis  document), 
this  value  was  estimated  at  80%.  In  other  words,  80%  of  energy  used  to  charge  the  batteries  was  assumed  to  be 
recoverable  from  the  cells. 


Operational  Time  per  Orbit 


o  u  o 

Inclination  (  )  Angle  of  Sun  From  Ascending  N< 

Figure  16  -  Spacequest  Power  Simulation 


Operational  Time  per  Orbit 


cx  u  o 

Inclination  ( j  Angle  of  Sun  From  Ascending  N< 

Figure  17  -  Emcore  Power  Simulation 

The  resulting  operational  times  were  fairly  similar,  with  only  several  minutes  difference  per  orbit  of  operational 
time. 


Decision 

In  the  end,  the  decision  was  made  to  go  with  Spacequest  for  solar  cell  supply.  While  the  cell  efficiency  was  lower, 
the  power  simulation  showed  that  the  mission  was  not  significantly  affected  by  the  loss  of  power.  The  reduced  cost, 
schedule  risk,  and  technical  risk  far  outweighed  the  reduced  power  availability. 
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Communication  Antennas 


Design  Trades 

The  Telemetry  and  Command  (T&C)  subsystem  had  wrestled  with  different  options  for  antenna  design  for  a  very 
long  time.  The  original  design  called  for  a  wire  loop  antenna  on  the  top  and  bottom  of  the  spacecraft.  During  the  fall 
of  2006,  the  team  members  decided  to  design  a  patch  antenna  using  a  dielectric  material  to  increase  efficiency.  No 
one  on  the  team  had  much  technical  experience  with  antenna  design,  so  a  system  level  trade  was  done  to  encourage 
outside  participation. 


Option  1  -  Wire  Loop  Antenna 

A  lot  of  analysis  had  been  done  early  on  with  this  antenna  design.  Link  budgets  and  initial  gain  pattern  simulations 
showed  that  it  would  most  likely  verify  requirements.  However,  no  one  on  the  team  had  the  technical  expertise  to 
verify  these  results.  This  antenna  would  be  simple  to  construct.  Initial  concerns  with  mounting  of  the  antenna  were 
relieved  when  the  AFRL  informed  the  team  that  epoxy  was  a  sufficient  means  of  affixing  the  antenna  [13]. 


Option  2  -  Patch  Antenna 

This  antenna  design  was  done  with  help  from  a  contact  at  Ball  Aerospace.  The  antenna  was  slightly  bigger  and 
harder  to  manufacture  due  to  the  rare  dielectric  material  used.  However,  the  simple  PCB-based  design  was  attractive 
and  the  gain  pattern  was  well  understood. 


Decision 

The  decision  was  made  to  return  to  the  original  design  upon  confirmation  of  the  gain  pattern  and  link  budget 
numbers.  The  patch  antenna  was  found  to  be  nearly  impossible  to  manufacture  and  was  a  large  burden  on  the  solar 
panels  as  it  was  larger  and  hard  to  place. 

Propulsion  Electronics 
Design  Trades 

The  original  design  of  the  Propulsion  Power  Unit  (PPU)  was  based  directly  off  of  a  heritage  design  from  the 
Dawgstar  program.  To  generate  the  2.8kV  required  for  Teflon  ablation,  the  Dawgstar  PPU  used  a  flyback  converter 
circuit.  CUSat  members  attempted  to  copy  this  configuration  but  ran  into  problems  with  design  of  the  central 
transformer.  AFRL  personnel  suggested  components  from  Pico  electronics  that  would  be  able  to  generate  the  high 
voltages  required  for  CUSat’s  PPU. 


Option  1  -  Flyback  Converter 

This  design  was  reasonably  well  understood,  however  design  of  the  transformer  had  caused  continual  delays  and 
burnouts  of  parts.  In  order  to  go  with  this  design,  the  transformer  issues  would  need  to  be  definitively  solved. 


Option  2  -  Pico  Electronics  Converters 

Pico  electronics  produces  high-voltage  DC-DC  converters.  These  “magic  black  boxes”  are  capable  of  producing  the 
required  voltage  to  charge  the  PPU  capacitors.  These  parts  were  recommended  by  members  of  the  AFRL.  However, 
availability  of  parts  and  space-worthiness  were  concerns  at  first.  These  concerns  were  later  alleviated  when  it  was 
found  that  Pico  can  produce  Aerospace  quality  versions  of  their  parts  that  meet  mil-specs.  The  cost  of  these  devices 
was  relatively  low  compared  to  the  unknown  costs  associated  with  the  transformer. 
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Decision 

In  this  case,  the  obvious  decision  was  to  go  with  the  devices  from  Pico  electronics.  It  was  a  better  decision  in  terms 
of  cost,  technical  risk,  and  schedule  risk. 


Camera  Interface  Circuit  Board 


System  Requirements 

HARN  S6. 


HARN  S6.1. 

HARN  S6.2. 

HARN  S6.3. 

HARN  S6.4. 

HARN  S6.5. 
[11] 


The  wiring  harness  shall  interface  to  COTS  devices  via  interface  boards. 

Source:  Error!  Reference  source  not  found. 

Interface  boards  shall  regulate  power  for  COTS  boards. 

Interface  boards  shall  monitor  voltage. 

Interface  boards  shall  monitor  current  consumption. 

Interface  boards  shall  monitor  COTS  board  temperature. 

Interface  boards  shall  communicate  with  C&DH. 


Design  Trades 


The  purpose  of  the  Camera  Interface  Board  (CAM  IB)  is  to  interface  the  Heron  FPGA,  which  controls  picture 
capture  from  the  cameras,  with  the  CUSat  data  bus.  The  original  design  of  this  board  had  to  be  scrubbed  before  FCR 
because  of  mislabeling  of  dimensions  on  the  enclosure.  A  new  board  was  designed  that  sat  on  the  side  of  the  box. 
The  trade  options  were  to  continue  with  this  design  or  to  replace  the  box  “side-board”  as  well  as  the  baseboard  for 
the  FPGA  with  a  single,  less  dense  board. 


Option  1  -  CAM  IB  with  "Side-Board" 

The  side-board  design  was  found  to  have  minor  flaws  during  FCR  integration.  Most  of  these  flaws  were  a  result  of 
improper  pin  numbering.  While  this  option  would  be  easy  to  redesign  to  remove  these  errors,  it  posed  several 
structural  issues  and  required  complicated  harnessing.  It  also  wasted  power  by  powering  an  unnecessary  base-board 
for  the  FPGA. 


Option  2  -  Replace  Baseboard 

For  this  option,  a  new  base-board  would  be  reverse  engineered  to  hold  the  FPGA.  This  would  eliminate  structural 
concerns  of  the  side-board  and  also  reduce  harnessing  and  power  consumption.  However,  there  was  significant 
technical  risk  as  a  new  board  design  is  always  risky. 

Decision 

The  decision  was  made  to  use  a  new  base-board  design.  This  required  significant  technical  work  on  the  part  of  the 
author.  Design  details  are  explained  in  the  Design  section.  While  this  increased  schedule  risk,  the  technical  risk  was 
low  and  the  new  design  mitigated  many  outstanding  structural  and  harness-related  issues. 
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Ground  Segment  and  Mission  Operations 
Requirements 

GS  SI.  The  Ground  Segment  shall  be  able  to  command  the  Flight  Computer. 

Source:  SYS  S16;  GS  FI 

GS  S2.  Multiple  ground  stations  shall  be  networked  together. 

Source:  Error!  Reference  source  not  found. 

tin 

Design  Trades 

There  were  two  software  packages  available  for  ground  station  support.  Orbital’s  MAESTRO  was  originally 
donated  to  the  program  sometime  in  2006.  However,  the  software  was  difficult  to  use  and  set  up.  The  contact  at 
Orbital  who  had  originally  offered  support  had  also  left  the  company.  L-3  Communication’s  InControl  software 
seemed  easier  to  integrated  and  set  up,  however  the  software  had  not  yet  been  obtained  by  CUSat. 


Option  1  -  MAESTRO 

MAESTO  is  very  well  respected,  real-time  software  for  satellite  control  and  mission  management.  CUSat  already 
had  two  licenses  donated  at  an  earlier  time.  However,  the  software  only  ran  on  Sun  Solaris  and  many  attempts  by 
CUSat  members  to  run  the  software  had  resulted  in  little  success.  Orbital  had  also  lost  interest  in  software  support. 


Option  2  -  InControl 

InControl  is  designed  to  be  high  reliability  software  for  fleets  of  satellites.  The  software  also  runs  on  Windows, 
which  was  a  big  benefit  for  CUSat  members.  However,  while  L-3  was  interested  in  donating  the  software,  we  had 
no  official  guarantee  that  this  would  go  through. 


Decision 

It  was  decided  that  CUSat  would  use  InControl  for  ground  segment  control.  The  features  and  support  far  outweighed 
the  risks  associated  with  using  MAESTRO.  L-3  representatives  were  very  helpful  and  the  license  donation  went 
through  quickly. 
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Results 


Hardware  Delivery 

Flight  delivery  was  originally  scheduled  for  January  2008.  The  AFRL  decided  to  push  this  date  back  to  March  2008 
to  accommodate  software  delivery  with  the  hardware.  However,  the  original  plan  of  hardware  delivery  by  January  is 
still  a  goal  of  the  program.  TABLE  XXX  shows  the  status  of  hardware  deliverables  as  of  the  writing  of  this  report. 


Table  2  -  Hardware  Status 


Electronics 

Status 

Description 

Arcom  Vipers 

Delivered 

GPS  Boards 

Delivered 

GPS  IB 

Delivered 

CDH  IB 

Delivered 

CAM  IB 

Testing  EDU 

The  parts  are  in  house.  Once  the  design  is  verified,  the  flight  units  will  be 
assembled. 

Power 

Harnessing 

Delivered 

Power 

Distribution 

Delivered 

T&C  Control 

Being 

Design  is  verified.  Boards  need  to  be  refabricated  due  to  population 

Board 

Refabricated 

error. 

Propulsion 

Control 

Ordered 

Need  to  verify  design  and  build  flight  units  once  the  parts  come  in. 

Propulsion 

Power 

Ordered 

Need  to  verify  design  and  build  flight  units  once  the  parts  come  in. 

Propulsion  D/I 

Ordered 

Need  to  verify  design  and  build  flight  units  once  the  parts  come  in. 

Camera  FPGAs 

Needs  Flight 

Prep 

Connectors  need  to  be  replaced. 

HAM  Radios 

Needs  Flight 

Needs  to  be  disasembled  and  prepared  for  integration.  Parts  are  in 

Prep 

house. 

Cameras 

Ordered 

Waiting  on  order. 

Diagnostic 

Board 

Mechanical 

Needs  Redesign 

Current  revision  works  for  ground  support,  but  a  new  version  is  desired. 

CDH  Box 

Delivered 

CAM  Lid 

Delivered 

Top  Wall 

Delivered 

Bottom  Wall 

Delivered 

Side  Walls 

Delivered 

HAM  Box 

Delivered 

Stiffener 

Delivered 

PPTs 

Need  to  make 

Waiting  on  Ultem  stock  to  make  nozzles. 

nozzles 
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Lifting  Harness 
*  —  * 

Assembly  Base 

Harnesses 
Periph  1 
Periph  2 
Periph  3 
Periph  4 
Camera  Data 

Power  Board- 

to-Board 

Umbillical 


Not  Manufactured 
Delivered 

Waiting  on  Parts 
Waiting  on  Parts 
Under  Construction 
Waiting  on  Parts 
Waiting  on  Parts 
Under  Construction 

Under  Construction 


For  the  electronics,  the  remaining  design  items  are  the  propulsion  boards  and  the  Diagnostic  Board.  The  propulsion 
boards  have  been  designed  and  parts  have  been  ordered.  Once  the  parts  come  in,  design  verification  with  a  test  unit 
will  begin.  This  process  should  conclude  before  the  end  of  the  calendar  year.  After  this,  assembly  of  the  flight  units 
will  begin  barring  any  unforseen  problems.  The  Diagnostic  Board  (DB)  is  a  lower  priority  and  therefore  has  been 
put  off  until  other  board  work  is  done.  The  DB  is  currently  in  its  second  revision.  The  second  revision  DB  is 
adequate  for  testing  of  almost  all  spacecraft  systems.  A  third  revision,  however,  is  needed  to  enable  easier 
integration  and  test  of  the  safety  inhibits. 

With  the  exception  of  the  PPT  nozzles,  all  mechanical  hardware  has  been  delivered.  All  hardware  has  been  anodized 
or  alodined  as  appropriate.  Fit  checks  have  been  performed  on  all  mechanical  hardware.  PPT  nozzles  have  been 
delayed  due  to  processing  issues  with  the  Ultem  stock.  Once  the  Ultem  order  goes  through  and  the  stock  arrives, 
manufacturing  will  begin  immediately.  This  will  most  likely  not  affect  the  delivery  schedule. 

Wiring  harness  construction  has  been  delayed  due  to  a  large  delay  in  the  connector  part  order.  These  parts  will 
slowly  trickle  in  over  the  next  few  weeks.  As  the  parts  come  in,  the  harnesses  will  be  constructed.  The  harness 
construction  schedule  puts  Periph  3,  the  Umbilical  harnesses,  and  the  power  connectors  first  since  these  are  first  on 
the  critical  path  for  flight  build  and  test.  These  parts  should  be  finished  before  the  end  of  the  calendar  year. 


Integration  and  Test 

Every  effort  is  being  made  to  ensure  that  hardware  is  ready  for  Integration  and  Test  (I&T)  once  the  spring  semester 
starts  in  January.  Several  pieces  of  flight  hardware,  including  the  CDH  IB  and  the  Power  Boards,  have  already  been 
run  though  their  official  test  plans.  The  remaining  hardware  testing  will  be  completed  in  January. 

CAM  IB 

The  CAM  IB  test  unit  has  been  populated  and  design  checkout  has  begun.  The  IB  correctly  powers  and  initializes 
the  Heron  FPGA5  board.  The  IB  also  correctly  implements  the  interface  to  the  flight  computer.  The  remaining  test 
items  include  using  the  board  to  take  a  picture  and  reprogramming  the  FPGA  using  the  JTAG  interface. 

The  backplane  connector  receptacle  board  that  was  part  of  the  CAM  IB  needs  to  be  reordered  due  to  pin  hole  sizing. 
This  should  be  relatively  inexpensive  and  very  low  risk. 

Power  Boards 

The  power  board  flight  units  have  been  populated  and  are  undergoing  testing.  The  design  verification  unit 
successfully  passed  all  tests.  The  flight  boards  are  currently  awaiting  loading  of  the  relays  and  will  then  be  sent  to 
the  Survivability  team  for  flight  preparations. 
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Conclusion 


Status  of  the  Program 

A  majority  of  hardware  items  have  been  delivered  as  of  the  writing  of  this  report.  The  ground  segment  and  mission 
operations  teams  have  made  significant  progress  this  semester  and  will  continue  to  train  new  team  members  and 
develop  solutions  next  semester.  With  machining  of  structural  parts  nearly  complete,  several  of  the  mechanical 
engineers  will  shift  focus  to  vibration  analysis  and  integration  work.  Most  electronics  parts  should  be  delivered  by 
the  end  of  the  calendar  year. 

Several  items  are  still  at  risk: 


Table  3  -  Risk  Assessment 


Items  at  Risk 

Schedule 

Technical 

Personnel 

Budget 

CAM  IB 

Wiring  Harness 

Propulsion  Electronics 

Propulsion  Igniters 

PPT  Manufacturing 

T&C  Control  Boards 

Software  Development 

T&C  Antenna  and  Radios 

The  CAM  IB  poses  some  schedule  risk  as  it  is  currently  behind  other  boards.  The  wiring  harness  has  been  delayed 
by  a  large  amount.  Additionally,  the  team  lost  experienced  harness  personnel  last  semester,  adding  technical  risk. 
The  propulsion  electronics  are  far  behind  schedule  compared  to  the  other  electronics  parts.  The  igniters  are  a  large 
risk  as  they  have  not  yet  fired  successfully. 

PPT  manufacturing  offers  mild  schedule  risk  as  it  depends  on  several  part  orders.  The  T&C  boards  are  currently 
behind  schedule  due  to  a  construction  error.  Software  development  is  still  in  early  stages,  and  therefore  poses  a  risk 
in  several  categories.  The  T&C  antenna  and  radios  are  far  behind  schedule  and  offer  large  technical  risks  to  the 
program. 

Future  Work 

This  winter  break  will  consist  of  a  large  push  to  catch  up  in  terms  of  electronics.  The  goal  is  to  deliver  all  the 
electronics  boards  before  the  year  is  over.  In  the  spring  semester,  work  will  focus  on  rapid  I&T  to  meet  the  March 
deadline.  Software  work  will  need  to  progress  to  the  testing  stage  where  software  can  be  tested  on  the  flight 
hardware. 

Figure  18  shows  the  overall  schedule  for  next  semester. 
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Figure  18  -  Forward  Looking  Schedule 
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13.  CUSat,  TC  Subsystem  Design  (CUSAT-D-TC-001D),  March  6,  2007 
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Action  Items  from  Post-FCR  Review 


ADCNS 

•  ACS  revising,  testing 

•  ADS  testing,  sun  ack 

•  MOMS  SW 

•  GNC  Supervisor 

•  Lightband  delivery,  configuration,  etc... 

•  GEONS  integration  &  test 

•  Position  controller 

o  Completing  orbital  design 
o  Determine  how  we  do  controller 

•  IMI- upgrade? 

o  Stop  vibrating! 
o  Another  supplier? 

•  Operations 

•  Spin  table 

•  Software  people 

•  ACS/delta  v  budget 

CAM 

•  Lens  -  does  it  fit  in  the  top  panel 

•  Camera  code  -  2  cameras 

•  Calibration  procedure 

•  Lens  mounting 

•  Vibe  test 

•  Mounting  bracket  didn't  line  up 

•  Focal  length 

•  Inter-cam  IB  connector 

•  Heater  &  thermistor  mounting 

•  Replace  the  base  board? 

•  Mechanical  fitting  of  baseboard 

CDH 

GS 

•  Need  software  people 

•  Re-contact  david  schevers 

•  Doppler  compensation  w/  TS-2000 

GPS 

•  Receiver  code  -  2  weeks  for  passing  around 

•  Capacitors  on  receivers 

•  ADS  test 


•  Top  and  bottom  walls 

•  Tight  lid  fits  on 

•  Stiffener 

•  Alodining  parts 

•  Flight  helicoil  replacement 

•  Cam  mount  hole  drills 

•  90  degree  edges  need  to  go,  they  need  to 
be  rounded 

o  Edge  rounding  spec  needs  to  be 
made 

HARN 

•  Cam  box  lid 

•  Active  sync  in  umbilical 

•  Harness  inventory 

•  Review  by  Dale  S. 

•  CAM  IB 

•  CDH  IB  mount  holes 

•  DB  new  Rev 

•  PCB  torque  values  for  airborn  connectors 
and  how  they  fit 

•  CAM  harness  tools 

PWR 

•  Solar  cell  design 

•  Next  revision 

•  Sensors 

•  Battery  box  design  +  assembly 

•  Lightband  boost  circuit 

•  Switches  on  driver,  boost 

•  12V  relay  order 

•  Centralized  distribution 

•  HAM  powering  (6V) 

•  Fault  tolerance  (cross-strapping) 

PROP 

PROP-E 

•  Igniter  test 

•  PPT  test  in  TVC 

•  Keep  current  PPU 

•  Dl  board  needs  to  be  screwed 


MANF 

•  Paperwork  traceability  PROP-M 

•  Consistency  in  CM/QA  rules 
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Particles  coming  off  of  PPTs  near  LV 
(mission  constraint) 

Testing 

o  Igniters 
o  New  PPU 
o  EMI 
o  Thermal 
Harness  design 


Lightband  POC,  lightband  contact  -  Matt 
Rozek 

Vibe  test  electronics  packaging  -  Megan 
Grounding  architecture  -  James  Maxwell 
Alternate  launch  configurations  -  Patrick 
Conrad 
FEA  -  Megan 


STR 

•  Honeycomb  panels  -  ask  the  AFRL 

•  Get  the  FEA  model  to  match  the  testing 

•  Wall  2  wall  connectors  is  a  crappy  design 

•  Fasteners 

o  JSC 
o  Ultem 

•  Alodine/anodize  parts,  need  to  research 
more 

•  Stand-offs  checkout  (ultem) 

•  Battery  box,  materials 

•  Lightband  people 

•  Tolerancing  analysis 

• 

SURV 

•  Materials - 

•  Conduction  pathways 

•  Testing  on  working  hardware 

•  Thermal  model  reflects  CONOPS  correctly 

•  Actual  thermistor  location  in  e-ics 

•  Tantalum  sheets  to  kill  SEUs 

TC 

•  Kenwood  radios  EMI  w/  PPTs 

•  SEUs  in  radio 

•  Radio  -  on/off  control  switch 

•  HAM  box  inside  the  wall 

•  Radio  design 

•  HAM  Radio  powering  voltage  range 

•  Cabling 

•  UCF  Radio  guy 

AI&T 

•  Assy  procedures  -  revise  each  one 

•  MGSE  needs  to  be  fixed,  finished 

•  Re-structure  procedures  to  help  mechanical 
integration 

•  Backplane  torquing  tool 

•  Need  to  assess  tools  for  each  procedure 

•  No  phillips  head  screws  on  spacecraft 

System-wide  issues 
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•  « 


3.0  Personnel  Supported 

The  only  paid  labor  on  this  program  is  that  of  Dr.  Jinwoo  Lee,  a  post-doctoral  researcher 
at  Cornell,  10%  of  whose  time  is  paid  by  the  program  for  his  participation  as  an  expert  in 
realtime  control  and  communications  electronics. 


4.0  Publications 

The  following  publications  and  presentations  have  appeared  the  inception  of  the  project: 

K.  Young,  J.  Fikentscher,  A.  Kelsey,  J.  Rostoker,  O.  Eldad,  D.  Gershman,  B.  Doyle,  K. 
Graf,  and  M.  Peck,  “A  GPS-based  Attitude  Determination  System  for  Small  Satellites,” 
2006  Small  Satellite  Conference,  Logan,  Utah,  August  14-17,  2006 

“The  Physics  of  Very  Small  Satellites,”  Miami  Museum  of  Science,  Miami,  FL,  Jan.  23, 
2006. 

“Systems  Architecture  for  an  In-Orbit  Inspection  Technology  Demonstrator,”  3rd  Mid- 
Atlantic  AIAA  Conference,  Baltimore,  MD.,  Nov.  5,  2005 

5.0  Interactions  and  Transitions 

5.1  Participation  and  Presentations 

Two  presentations  have  come  out  of  this  project.  Dr.  Peck  provided  a  keynote  speech  at 
the  Mid-Atlantic  Regional  Conference  on  November  5,  2005.  He  presented  an  overview 
of  the  CUSat  project,  including  its  connection  with  responsive-space  efforts  and  NASA’s 
Vision  for  Space  Exploration.  Deborah  Sunter,  the  Ground  Segment  lead,  presented  her 
paper  on  CUSat  Concept  of  Operations. 

5.2  Consultative  and  Advisory  Functions 

Dr.  Peck  serves  as  a  consultant  in  Spacecraft  Systems  Engineering.  In  addition  to  his 
industry  background,  his  CUSat  experience  has  been  brought  to  bear  for  consulting  with 
Boeing  Satellite  Systems,  where  engineers  are  creating  a  process  for  training  in 
requirements  development.  His  contributions  include  proposing  an  object-oriented 
requirements-allocation  process,  the  same  one  used  on  CUSat.  The  Applied  Physics  Lab 
may  also  bring  in  Dr.  Peck  for  consulting  activities  related  to  classified  nanosatellite 
project  proposals.  Those  discussions  are  ongoing.  Dr.  Peck  also  recently  served  on  a 
panel  reviewing  the  spacecraft  design  project  for  final-year  students  at  the  Naval 
Postgraduate  School. 

5.3  Transitions 

CUSat’ s  innovative  use  of  CDGPS  for  attitude  and  navigation  is  being  considered  for 
adoption  by  Northrop  Grumman  Space  Systems.  They  are  collaborating  with  Cornell  in 
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^^development  of  a  responsive  ground  segment  for  inspection-related  data  products. 
These  promising  collaborative  possibilities  add  value  to  the  CUSat  project  and  provide 
encouragement  to  the  students. 


6.0  Inventions  and  Patent  Disclosures 

CUSat  has  not  patented  its  technologies. 
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